This says public and private, but nothing in the workflow detects repo visibility or skips accordingly, and the permissions block below only works for public repos today. Two coherent options:

• If private is genuinely in scope: fix the permissions (see the comment on the permissions: block) so private callers actually work.
• If this is public-only in practice (publish_results / badge / REST API are all public-only per the README note): guard it, e.g. if: ${{ !github.event.repository.private }} on the job, or fail fast, and reword this line.

As written it is neither: it advertises private support it cannot deliver, with no guard to skip private callers.

required: true combined with a default: is contradictory for workflow_call inputs: required forces the caller to pass a value, so the default is unreachable, yet the README lists these as Required with a default. Set required: false (the defaults are sensible) or drop the defaults. Same applies to results_format just below.

repo_token is declared here as an input and as a secret (lines 6-8). Every step reads secrets.repo_token; this input is never referenced. The hello-world run shows it riding along empty in the Inputs dump while the real token arrived via secrets:. The README Inputs table documents it as a with: input, so a caller who follows the table will have it silently ignored. Drop this input, keep the secret, and move the README row into a Secrets section.

Blocking: this token is missing contents: read (plus actions: read, pull-requests: read).

Because this block is an explicit allow-list, the token that reaches analysis is exactly these two scopes. Confirmed in the hello-world run (digicatapult/hello-world#25), where the job's own token dump reads only:

Metadata: read
SecurityEvents: write

Consequences:

1. Checkout code clones with this token, so on a private caller repo it fails outright. Public repos clone unauthenticated, which is the only reason hello-world stayed green.
2. Even on public repos, several requested checks (Branch-Protection, Code-Review, Token-Permissions, Signed-Releases) need contents/pull-requests read to evaluate, so they silently degrade while the job still exits 0, giving a falsely reassuring pass.

This also contradicts the repo's own guidance in README.md:41 (private callers need contents: read, actions: read, pull-requests: read).

Suggested:

    permissions:
      security-events: write
      id-token: write
      contents: read
      actions: read
      pull-requests: read

and mirror it in the two example callers and the README permissions table.

${{ inputs.custom_checks }} here (and results_file, file_mode, scorecard_version, github.repository elsewhere in this block, plus line 104) is expanded into the script text before bash runs, which is the script-injection pattern our CLAUDE.md calls out (never interpolate into shell commands). Callers are trusted so the blast radius is bounded, but this assembles a docker run command line, so please pass these via env: and reference "$CUSTOM_CHECKS" etc., exactly as you already do for GITHUB_AUTH_TOKEN / ENABLE_SARIF.

Pin drift from the rest of the repo: every other workflow is on actions/checkout@v7, this is a major version behind on @v6.0.2. actions/upload-artifact@v7.0.1 (line 146) is also pinned to a patch tag where the repo uses @v7. Please align both with the repo convention.

github/codeql-action/upload-sarif requires a SARIF file, but nothing prevents results_format: json + upload_type: dashboard, which would fail at this step. Relatedly, the artifact step above hardcodes name: SARIF file even for JSON output. Consider validating (json implies artifact-only) or documenting the constraint, and making the artifact name format-aware. Only the sarif+artifact path was exercised in the hello-world run, so this combination is currently untested.

This table omits contents: read (and actions: read / pull-requests: read), which private callers need per the repo's own note at README.md:41 and which the analysis job requires for checkout and for several of the checks. Please add them here and in the two example callers once the workflow permissions block is fixed.